FIG. 1 shows a diagram of the protocol stack for UMTS. The radio interface is layered into three protocol layers:                the physical layer (L1);        the data link layer (L2);        the network layer (L3).        
A more detailed description is outlined in the 3GPP specification document TS 25.301.
Layer 2 is split into following sub-layers: Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP) and Broadcast/Multicast Control (BMC). Layer 3 and RLC are divided into Control (C-) and User (U-) planes. PDCP and BMC exist in the U-plane only. In the C-plane, Layer 3 is partitioned into sub-layers where the lowest sub-layer, denoted as Radio Resource Control (RRC), interfaces with layer 2 and terminates in the UTRAN. Service Access Points (SAP) for peer-to-peer communication are marked with circles at the interface between sub-layers. The SAP between MAC and the physical layer provides the transport channels. The SAPs between RLC and the MAC sub-layer provide the logical channels.
Also shown are connections between RRC and MAC as well as RRC and L1 providing local inter-layer control services. These interfaces allow the RRC to control the configuration of the lower layers. For this purpose, separate Control SAPs are defined between RRC and each lower layer (PDCP, RLC, MAC, and L1). The RLC sub-layer can provide retransmission functionality as well as segmentation/reassembly functionality. The MAC sub-layer provides mapping of the logical channel(s) onto the appropriate transport channel(s), the selection of appropriate Transport Format Combinations and the multiplexing/demultiplexing of higher layer Protocol Data Units (PDU) into/from transport channel PDUs (called Transport Block). That means a MAC PDU is defined as a RLC PDU plus a MAC header.
The RLC provides three main delivery services to higher layers:                TM (Transparent Mode): does not add header information to higher layer PDUs; however, it may segment the information if required, with the size of the segments being determined from the transport formats.        UM (Unacknowledged Mode): as TM above, but also allows for concatenation of higher-layer PDUs; thus a header is required.        AM (Acknowledged Mode): provides segmentation and reassembly, concatenation, error correction, in-sequence delivery of higher-layer PDUs, duplicate detection, flow control, and ciphering.        
FIG. 2 shows the MAC header and data payload as currently defined for release 6 of UMTS in the Downlink (for High Speed Downlink Packet Access HSDPA). The MAC header comprises:                VF (Version Flag) for extension capabilities;        Queue ID for identification of the reordering queue on the UE (User Equipment) side;        TSN (Transmission Sequence Number) used for reordering purposes (i.e. the received MAC PDUs are reordered according to their associated TSN);        SIDk (Size Index iDentifier), which indicates the size of a set of consecutive PDUs of the same length;        Nk, which represents the number of consecutive PDUs;        Fk, which is a flag indicating if SIDk or a PDU is following (0=SID follows, 1=PDU follows).        
Proposals have been made to design the MAC and RLC in release 7 of UMTS as follows. The RLC-AM (Radio Link Control Acknowledged mode) will be enhanced to support flexible PDU sizes (a PDU comprises data and control information which is passed between layers in a protocol stack). The MAC-hs (i.e. the MAC entity in the base station controlling the High Speed Downlink Shared CHannel HS-DSCH) will be enhanced to support RLC PDU segmentation. The SID and N fields (SID identifies logical channel and the size of N consecutive RLC PDUs and N the number of consecutive RLC PDUs) need to be updated in order to be able to indicate the size of the RLC PDU. It seems highly likely that backwards compatibility will be maintained by using the VF flag in the MAC-hs header.
The design of the RLC should take into account the available memory in a given implementation for the processing of layer 2 data, the maximum RLC window size (namely the currently acceptable range of sequence numbers to the receiver) supported and the RLC round-trip-time. If the number of RLC PDUs is increased for a given amount of data then the RLC transmission window will advance faster and the receiver generate more ACK/NACKs (ACKnowledgement/Negative ACKnowledgement) in the status reports. There has been a drive to reduce L2 RLC RTT to avoid RLC window stalling. RLC window stalling is when the RLC entity has to wait (i.e. window cannot advance) for a re-transmission and positive acknowledgment of a PDU. The maximum sustainable rate can be estimated by:Rate=window size*PDU Size/RTT (assuming zero RLC-level retransmissions).
With typical assumptions of a 2047 RLC window size (4095 is the maximum), a 100 ms round trip delay between RLC and UE and a 320 bit RLC PDU size, an error less flow would sustain a maximum data rate of 2047*320/0.1=6.55 Mbps (13.1 Mbps with 640 bit PDUs).
As seen above, the maximum sustainable data rate of RLC would not be high enough to support the expected data rates (greater than 14 Mbps) when MIMO or higher-order modulation (64 QAM) is used in Release-7 UMTS. Therefore, some improvements to layer 2 have to be made.